基于Docker实现DevOps的一些探索
DevOps介绍
DevOps(Deveplopment和Operations的简称)，中译为开发运维一体化，可定义为是一种过程、方法、文化、运动或实践，主要是为了通过一条高度自动化的流水线来加强开发和其他IT职能部门之间的沟通和协作，加速软件和服务的交付。
在一个较成熟的软件和服务交付的团队里，就技术层面来说主要分为三个组成部分:开发、测试和运维。DevOps的作用就是将这三个部分紧密的连接起来，提供一条从软件开发到质量保障到技术运营的自动化流水线，加强不同角色之间的沟通和协作，基于用户需求实现软件和服务的快速交付。
"开发的这群傻叉新给的发布包又把系统CPU搞到100%了，应用又夯住了，都是些什么水平的人啊..."
"运维的这帮傻鸟技术太差，维护的是些什么稀烂的系统，在我这跑得好好的，上他们那应用就挂..."
"这是开发的锅..."
"这是运维的盘..."
描述得略显浮夸...但这种踢皮球的事情在IT公司里面真的是随处可见。无谓对错，也无锅可背，都是由开发和运维的基因所决定，但是最终的受害者却是用户。偏偏比较有意思的就是，开发和运维人员所做的这些也都是为了用户，开发人员必须根据用户的需求对应用的功能进行不停的变更，运维人员也必须根据用户的需求提供稳定和持续的服务。各司其职的同时也在两者之间形成了一面无形的墙，阻碍了开发和运维之间的沟通和协作，而DevOps的出现就是为了击碎这堵无形之墙。
DevOps落地的思考
技术层面
DevOps不是一个工具，但它需要被工具来实现，好在现今已经有了很多商业版和开源版的软件来形成一个有效的工具链来作为DevOps技术层面的支撑。但是光有工具还不够，再好的工具没人会用也没意义，所以需要有熟悉这个工具链的IT人员来提供技术支持，利用工具实现DevOps的高度自动化。
流程层面
DevOps是一条从开发到运维的流水线，想要流水线能够高效的自动运行，必须要设定一系列的流程和规范来进行管控。IT的管理者需要有基于软件或服务交付的全局观，能够清晰的认识到交付周期中不同角色的痛点在哪里，进而定制出合适的协作流程。
组织层面
DevOps并不是简单的将开发部门和运维部门合并，而是加强开发部门和运维部门之间的协作和沟通。这需要管理者们对企业的IT部门有着足够的重视并且愿意去推动DevOps这种开发和运维间高效协作的模式，并且开发和运维的人员之间也需要有开放、接纳和协作的意识。
DevOps是一个虚无缥缈的玩意儿，它并不能被工具或软件来简单的定义或量化。但工具或软件却是实现DevOps的一个重要组成部分，而Docker就是实现DevOps最合适的工具之一。
Docker介绍
Docker是一个分布式应用构建、迁移和运行的开放平台，它允许开发或运维人员将应用和运行应用所依赖的文件打包到一个标准化的单元(容器)中运行。
容器是一个非常早期的技术，Unix的chroot功能可以说是容器的雏形，而后到大家所熟知的基于Namespace和Cgroups技术的LXC(Linux Container)，最后到现在如日中天的Docker。站在前人的肩膀之上，Docker最妙的地方就是将容器的使用简单化和标准化，再配合一波开源，互联网，云计算，大数据的浪潮，可谓是时代的宠儿。
很多人都喜欢拿容器和虚拟机对比，其实容器和虚机都是属于虚拟化技术的一种实现。两种架构在底层上相同，需要物理硬件和操作系统的支持。不同的是虚拟机场景中，Hypervisor(如KVM)作为操作系统到虚拟机的中间层,而容器场景中Docker Engine(以Docker为例)作为操作系统到容器的中间层。虚机封装操作系统和应用，而容器则直接封装应用，这也是为什么容器要比虚机轻量的原因。
上图中将虚拟机和容器的特性进行了对比，可以看出容器相对于虚拟机比较有优势的地方就是轻量、灵活、资源利用率高。缺点主要就是隔离性不如虚拟机，也就是一直被无限放大的容器的安全性问题。但偏偏就是因为容器没有完全被隔离到一个密封的小黑屋里面，所以才能带来比虚拟机更好的资源利用率。
个人认为容器在短期之内还取代不了虚机，在未来很长一段时间内会是容器和虚机并存的情况。而到最终谁替代谁，取决的不是技术本身，而是用户体验时代的需求。
PS:希望有朋友能够发现此图中的一点小漏洞。
Docker基本组件介绍
Docker Image
Docker镜像是一个运行容器的只读模板。Docker Container
Docker容器是一个运行应用的标准化单元。Docker Registry
Docker注册服务器用来存放镜像。Docker Engine
Docker引擎用来在主机上创建，运行和管理容器。
了解Docker的朋友都知道,Docker将自身最主要的特点以下面这一句话来描述"Build,Ship and Run Any App Anywhere"。Build出Image，然后使用Registry来Ship镜像，最终使用Engine将Container和包含的App在任意平台(Anywhere)上运行起来。
Docker原生工具介绍
Docker Machine 让用户在基础架构平台快速部署Docker宿主机
Docker Swarm 让用户在集群环境中调度和运行容器
Docker Compose 让用户在集群环境中编排和部署应用
这三个工具构成了Docker的原生环境，加上比较火的k8s,Mesos,Rancher,etcd等外部生态，构建出了一个比较完整的Docker容器生态圈。对于原生工具和外部工具，个人觉得工具或技术并没有好坏之分，主要还是看适用场景和客户需求。而正是有这些生态的合作和竞争造就的乱世，才促进了容器技术的高速发展和逐步成熟。
Docker适用的场景
持续集成和持续交付
开发运维一体化
容器云
大数据
Docker官方给的Use Case是CI/CD,DevOps,Big Data和Infrastructure Optimization(Cloud)。
这里比较有意思的就是，这几个使用场景似乎正好描绘着Docker当前的发展史。
起初Docker的出现主要面向的对象是开发者，为开发者提供应用快速开发和测试的环境，这就是CI/CD所在的场景。
随后的发展使得Docker不再仅仅只关注开发层面的东西，而在向运维层面迈进，就出现了DevOps的场景。
既然有了运维，那肯定避免不了接触到基础架构的东西，而现今的基础架构基本都是围绕着云计算来展开，所以Docker又涉及到了基础架构优化的层面，也就是Container Cloud。
基础架构的容器云有了，那么势必需要对云中的应用提供服务，加上Docker自身的许多优势，自然而然的又涉及到了Big Data的使用场景。
而Docker自身的解决方案Docker Cloud和Docker Data Center的先后推出也侧面反应了从开发到运维场景的逐步支持。DDC的出现更是将目标直接瞄准了企业内部容器云。
难以分清是新技术成就了Docker，还是Docker承载了新技术。至少就目前来看，Docker的发展方向是顺应这个时代的。这只是三岁多的Docker，不敢想象它在将来会有多大的能量爆发出来，将这些留给时间去述说。
Docker实现DevOps的优势
优势一
开发、测试和生产环境的统一化和标准化。镜像作为标准的交付件，可在开发、测试和生产环境上以容器来运行，最终实现三套环境上的应用以及运行所依赖内容的完全一致。
优势二
解决底层基础环境的异构问题。基础环境的多元化造成了从Dev到Ops过程中的阻力，而使用Docker Engine可无视基础环境的类型。不同的物理设备，不同的虚拟化类型，不同云计算平台，只要是运行了Docker Engine的环境，最终的应用都会以容器为基础来提供服务。
优势三
易于构建、迁移和部署。Dockerfile实现镜像构建的标准化和可复用，镜像本身的分层机制也提高了镜像构建的效率。使用Registry可以将构建好的镜像迁移到任意环境，而且环境的部署仅需要将静态只读的镜像转换为动态可运行的容器即可。
优势四
轻量和高效。和需要封装操作系统的虚拟机相比，容器仅需要封装应用和应用需要的依赖文件，实现轻量的应用运行环境，且拥有比虚拟机更高的硬件资源利用率。
优势五
工具链的标准化和快速部署。将实现DevOps所需的多种工具或软件进行Docker化后，可在任意环境实现一条或多条工具链的快速部署。
实例分享
架构介绍
该DevOps环境基于开源产品Rancher进行管理，分为三套环境和一套横跨各环境的私有Registry。基于RancherUI和Docker宿主机，每套环境对不同的角色配置权限管理，每个角色仅能访问对应的环境。开发、测试和运维人员可自由选择Web UI或Docker CLI的方式去管理自己的环境。
DEV ENV
定义为开发环境，包含开发人员客户端的笔记本和服务端的一台Docker主机。
**TEST ENV **
定义为测试环境，包含测试人员客户端笔记本和服务端的一台Docker主机。
OPS ENV
定义为运维环境，包含运维人员客户端笔记本和服务端的两台Docker主机构建的Swarm集群。
**Pri-Registry **
私有镜像服务器，整个DevOps流水线中的核心。将镜像作为最终的交付件在不同的环境中Ship和Run，以实现从Dev到Ops应用环境的一致性部署。
运作流程
开发者通过本地的Git客户端向服务端的Gogs提交代码，Jenkins将代码构建成镜像放到本地。开发人员将对应的镜像启动容器来预览的开发结果。如果确认已满足预期，则将该镜像推送到私有的Docker注册服务器中进行存储。
测试人员将私有镜像仓库中开发人员新提交的镜像运行成容器，并进行手动或者自动的功能性测试，测试通过后镜像会被打上一个新的Tag以被其他环境使用。
运维人员基于私有镜像仓库中被打过Tag的镜像启动为容器，最终交付给客户。
目前该环境主要用于Docker Image的构建和发布，Ops(Prod)环境中跑了一些项目内部使用的应用，但更多的是作为Demo环境提供给客户访问而并非真正意义上的生产环境。